home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17849 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.5 KB
  1. Path: newsfeed.concentric.net!news
  2. From: "Alan L. Lovejoy" <alovejoy@concentric.net>
  3. Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
  4. Subject: Re: Will Java kill C++?
  5. Date: Wed, 17 Apr 1996 13:15:32 -0700
  6. Organization: Modulation
  7. Message-ID: <31755164.79F8@concentric.net>
  8. References: <3134D499.653E@ix.netcom.com> <313613B2.136E@ksopk.sprint.com> <4i7qhl$ik6@cronkite.seas.gwu.edu> <4iuhi7$fmf@sundog.tiac.net> <4iumap$mn5@hustle.rahul.net> <31582A45.3742@vmark.com> <3163C031.4FB1@esec.ch> <3164888D.2B01@concentric.net> <4kbfn8$1bu@news1.is.net> <4kqjf6$kh0@kaiwan009.kaiwan.com> <317173F1.5790@concentric.net> <4l194e$q11@galaxy.ucr.edu> <31743669.62A1@concentric.net> <4l3432$ebu@galaxy.ucr.edu>
  9. NNTP-Posting-Host: cnc009039.concentric.net
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.01Gold (Win95; U)
  14.  
  15. Tom Payne wrote:
  16. > 
  17. > Alan L. Lovejoy (alovejoy@concentric.net) wrote:
  18. > : Tom Payne wrote:
  19. > : >
  20. > : > Alan L. Lovejoy (alovejoy@concentric.net) wrote:
  21. > : > :
  22. > : > : I did those benchmars to prove that Smalltalk message sends are faster
  23. > : > : than c function calls.  To do that, I needed a benchmark that consisted
  24. > : >
  25. > : > How is that possible, given that the message has to find the entry
  26. > : > point of the method and has to communicate parameters by mechanisms
  27. > : > not unavailable to C.
  28. > :
  29. > : It's a fact.  It's possible because full method lookup only needs to
  30. > : occur the first time a message is sent to a receiver of a particular
  31. > : class, not each time a message is sent--and because message sends do not
  32. > : use "JSR/BSR" machine instructions, but just use simple jumps or
  33. > : branches.  Remember, method contexts are allocated on the heap, not on
  34. > : the stack.
  35. > 
  36. > This shows that a particular implementation of Smalltalk message sends
  37. > is faster than a particular implementation of C function calls, which
  38. > is both surprising and interesting, but does not show message sends to
  39. > be inherently faster.  (Perhaps, all you are claiming is the relative
  40. > performance in a particular case.)
  41.  
  42. Exactly.  This benchmark was done for a client whose platform was Sun
  43. workstations.  VisualWorks versus C on the SPARC was what mattered.
  44. I realize full well that results may be different on other hardware.
  45.  
  46. But the mere fact that this result could be obtained on any platform
  47. is very informative, I think.
  48.  
  49. > As I recall, the standard trick for eliminating most of the overhead
  50. > of method lookups on message sends is to cache the method on each send
  51. > and next time check for correctness.  Of course, this correctness
  52. > check is overhead that is unnecessary in C.  The fact that in this
  53. > implementation method contexts are allocate on the heap, not the
  54. > stack, leaves me even more puzzled; heap allocation is no faster, in
  55. > fact almost always slower, than stack allocation, which merely
  56. > involves incrementing a pointer.
  57. > 
  58. > Tom Payne (thp@cs.ucr.edu)
  59.  
  60. Smalltalk gets little or no benefit from the work done by a subroutine 
  61. call instruction.  It doesn't need to pass arguments in registers, and it 
  62. doesn't need register windows.  There is no need to save and restore
  63. register values on the stack each time a method is called, because 
  64. the method arguments and temporaries are heap-allocated--this could
  65. account for a significant portion of the surprising speed difference.
  66. C compiled code is optimized for relatively infrequent function calls.
  67. Smalltalk is optimized for dense message sending--just about everything
  68. is done by message send.
  69.  
  70. --Alan
  71.